1. Field
This disclosure relates generally to packet flow and, more specifically, to bidirectional packet flow transformation.
2. Related Art
As network processors become more pervasive, technology is constantly developing to provide more flexibility and improved capabilities with respect to network packet processing features. Network processors process and route packets formatted according to a given protocol (e.g., transmission control protocol (TCP)), based on computations performed on packet fields. A traditional limitation related to packet processing in network processors is packet flow bi-directionality. In general, existing network processors do not allow optimal identification of functional packet flows for packets exchanged in either direction on a connection.
For example, a TCP connection is essentially bidirectional since it is set-up as a reliable communication channel between two hosts (i.e., a “source” host initiating the TCP connection that triggers the connection set-up process with an exchange of specific “sync” packets with a “destination” host that participates in the connection set-up process by responding to the source host in a return IP path). Once the TCP connection is established, the connection runs under a flow control scheme that involves the exchange between the hosts of the position inside the byte stream (windowing) and congestion information (“ack”). In sum, TCP exchange relies on symmetrical exchange of control information between two hosts.
In general, some network processor applications are involved in the management of only one side of a network connection, while other network processor applications are involved in the management of both sides of the network connection. For example, an “end-point” application is typically involved in the termination of a TCP connection, as an end-point application runs on only one of two hosts communicating over the TCP connection. A major hardware off-load process in end-point applications is to classify incoming packets so that a receive queue is selected to receive all packets belonging to one or several TCP connections. As another example, a “network node” application is typically involved in the interception of a TCP connection, as a network node application runs in an intermediate point in the network to support the TCP connection between two hosts.
A common way to operate applications monitoring network connections is to expose them to the aggregation of all traffic received in a network node. That is, all packets received from all ports of a network processor are forwarded to the applications controlling the network node. This implies that a network node application receives packets from both sides of a TCP connection, although each side is usually on a different port. Existing solutions do not allow a classification of incoming packets by network connection independent of which port has received the packet, i.e., a same classification usually cannot be performed for packets related to the two sides of a same network connection. Accordingly, packets of both sides of the network connection cannot be easily managed to be received in a same receive queue and/or sent for final processing to a same processing core or thread.